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Abstract 


This document describes a number of use cases together with 
directions and interpretations for organizations and relying parties 
when creating or encountering Resource Public Key Infrastructure 
(RPKI) object scenarios in the public RPKI. All of these items are 
discussed here in relation to the Internet routing system. 
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Introduction 


This document describes a number of use cases together with 
directions and interpretations for organizations and relying parties 
when creating or encountering Resource Public Key Infrastructure 
(RPKI) object scenarios in the public RPKI. All of these items are 
discussed here in relation to the Internet routing system. 


1. Terminology 


It is assumed that the reader is familiar with the terms and concepts 
described in "Internet X.509 Public Key Infrastructure Certificate 
and Certificate Revocation List (CRL) Profile" [RFC5280], "A Profile 
for X.509 PKIX Resource Certificates" [RFC6487], "X.509 Extensions 
for IP Addresses and AS Identifiers" [RFC3779], "A Profile for Route 
Origin Authorizations (ROAs)" [RFC6482], "Validation of Route 
Origination Using the Resource Certificate Public Key Infrastructure 
(PKI) and Route Origin Authorizations (ROAs)" [RFC6483], and "BGP 
Prefix Origin Validation" [RFC6811]. 


-2. Documentation Prefixes 


The documentation prefixes recommended in [RFC5737] are insufficient 
for use as example prefixes in this document. Therefore, this 
document uses RFC 1918 [RFC1918] address space for constructing 
example prefixes. 


.3. Definitions 


For all of the use cases in this document, it is assumed that RPKI 
objects (e.g., resource certificates, ROAs) validate in accordance 
with [RFC6487] and [RFC6480]. In other words, we assume that 

corrupted RPKI objects, if any, have been detected and eliminated. 


The following definitions are in use in this document. Some of these 
definitions are reused or adapted from [RFC6811] with authors’ 
permission. 


Resource: An IP address prefix (simply called prefix or subnet) or 
an Autonomous System Number (ASN). 


Allocation: A set of resources provided to an entity or organization 
for its use. 


Sub-allocation: A set of resources subordinate to an allocation 
assigned to another entity or organization. 
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Prefix: A prefix consists of a pair (IP address, prefix length), 
interpreted as is customary (see [RFC4632]). 


Route: Data derived from a received BGP update, as defined in 
[RFC4271], Section 1.1. The route includes one prefix and an 
AS_PATH, among other things. 


ROA: Route Origin Authorization (ROA) is an RPKI object signed by a 
prefix holder authorizing origination of said prefix from an 
origin AS specified in said ROA. 


AS 0 ROA: A ROA with ASN value 0 (zero) in the AS ID field. AS 0 
ROA is an attestation by a prefix holder that the prefix described 
in the ROA, and any more specific prefix, should not be used ina 
routing context [RFC6483]. 


ROA prefix: The prefix from a ROA. 
ROA ASN: The origin ASN from a ROA. 


maxLength: The maximum length up to which more specific prefixes of 
a ROA prefix may be originated from the corresponding ROA ASN. 
The maxLength is specified in the ROA. 


Route prefix: A prefix derived from a route. 


Route origin ASN: The origin AS number derived from a route. The 
origin AS number is: 


o the rightmost AS in the final segment of the AS_PATH attribute 
in the route if that segment is of type AS_SEQUENCE, or 


o the BGP speaker’s own AS number if that segment is of type 
AS_CONFED_SEQUENCE or AS_CONFED_SET or if the AS_PATH is empty, 
or 


o the distinguished value "NONE" if the final segment of the 
AS_PATH attribute is of any other type. 


Covering ROA prefix: A ROA prefix that is an exact match or a less 
specific when compared to the route prefix under consideration. 
In other words, the route prefix is said to have a covering ROA 
prefix when there exists a ROA such that the ROA prefix length is 
less than or equal to the route prefix length and the ROA prefix 
address matches the route prefix address for all bits specified by 
the ROA prefix length. 
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Covering ROA: If a ROA contains a covering ROA prefix for a route 
prefix under consideration, then the ROA is said to be a covering 
ROA for the route prefix. 


No covering ROA: No covering ROA exists for a route prefix under 
consideration. 


No other covering ROA: No other covering ROA exists (besides what is 
(are) already cited) for a route prefix under consideration. 


Multi-homed prefix or subnet: A prefix (i.e., subnet) for which a 
route is originated through two or more autonomous systems. 


Matched: A route’s {prefix, origin AS} pair is said to be matched by 
a ROA when the route prefix has a covering ROA, and in addition, 
the route prefix length is less than or equal to the maxLength in 
said covering ROA and the route origin ASN is equal to the ASN in 
said covering ROA. 


Given these definitions, any given BGP route will be found to have 
one of the following "validation states": 


o NotFound: The route prefix has no covering ROA. 


o Valid: The route’s {prefix, origin AS} pair is matched by at least 
one ROA. 


o Invalid: The route prefix has at least one covering ROA and the 
route’s {prefix, origin AS} pair is not matched by any ROA. 


It is to be noted that no ROA can have the value "NONE" as its ROA 
ASN. Thus, a route whose origin ASN is "NONE" cannot be matched by 
any ROA. Similarly, no valid route can have an origin ASN of zero 
[ASO-PROC]. Thus, no route can be matched by a ROA whose ASN is zero 
(i.e., an AS 0 ROA) [RFC6483]. 


2. Overview 
2.1. General Interpretation of RPKI Object Semantics 


In the interpretation of relying parties (RPs), or relying party 
routing software, it is important that a ’make before break’ 
operational policy be applied. In part, this means that an RP should 
implement a routing decision process where a route is assumed to be 
intended (i.e., considered unsuspicious) unless proven otherwise by 
the existence of a valid RPKI object that explicitly invalidates the 
route (see Section 7.1 for examples). Also, especially in cases when 
a prefix is newly acquired by allocation/sub-allocation or due to 
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prefix-ownership transfer, a ROA should be registered in RPKI prior 
to advertisement of the prefix in BGP. This is highly recommended 
for the following reasons. Observe that in the transfer case 
(considering a prefix transfer from Org A to Org B), even though Org 
A’s resource cert would be revoked before issuing a resource cert to 
Org B, there may be some latency before all relying parties discard 
the previously received ROA of Org A for that prefix. The latency 
may be due to CRL propagation delay in the RPKI system or due to 
periodic polling by RPs, etc. Also, observe that in the 
sub-allocation case (from parent Org A to child Org B), there may be 
an existing ROA registered by Org A (with their own origin ASN) fora 
covering aggregate prefix relative to the prefix in consideration. 
If the new prefix owner (Org B) has not already registered their own 
ROA (i.e., ROA with their origin ASN), then the presence of a 
different covering ROA (i.e., one with a different origin ASN) 
belonging to Org A would result in invalid assessment for the route 
advertised by the new owner (Org B). Thus, in both cases (transfer 
or sub-allocation), it is prudent for the new owner (Org B) to ensure 
that its route for the prefix will be valid by proactively issuing a 
ROA before advertising the route. The ROA should be issued with 
sufficient lead time taking into consideration the RPKI propagation 
delays. 


As stated earlier in Section 1.3, for all of the use cases in this 
document, it is assumed that RPKI objects (e.g., resource 
certificates, ROAs) validate in accordance with [RFC6487] and 
[RFC6480]. In other words, we assume that corrupted RPKI objects, if 
any, have been detected and eliminated. 


While many of the examples provided here illustrate organizations 
using their own autonomous system numbers to originate routes, it 
should be recognized that a prefix holder need not necessarily be the 
holder of the autonomous system number used for the route 
origination. 


3. Origination Use Cases 


This section deals with the various use cases where an organization 
has Internet resources and will announce routes to the Internet. 

It is based on operational observations of the existing routing 
system. In the following use cases, the phrase "relying parties 
interpret the route as intended" is generally meant to indicate that 
"relying parties interpret an announced route as having a valid 
origination AS". 
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3.1. Single Announcement 
An organization (Org A with ASN 64496) has been allocated the prefix 
10.1.2.0/24. It wishes to announce the /24 prefix from ASN 64496 


such that relying parties interpret the route as intended. 


The desired announcement (and organization) would be: 


4---------------------------------------------- + 
| Prefix | Origin AS | Organization | 
4+---------------------------------------------- + 
| 10.1.2.0/24 | AS 64496 | Org A | 
4+---------------------------------------------- + 


+---------------------------------------------—- + 
| asID | address | maxLength 
+---------------------------------------------- + 
| 64496 | 10.1.2.0/24 | 24 
+---------------------------------------------- + 


3.2. Aggregate with a More Specific 


An organization (Org A with ASN 64496) has been allocated the prefix 
10.1.0.0/16. It wishes to announce the more specific prefix 
10.1.0.0/20 from ASN 64496 as well as the aggregate route such that 
relying parties interpret the routes as intended. 


The desired announcements (and organization) would be: 


4---------------------------------------------- + 
| Prefix | Origin AS | Organization | 
4+---------------------------------------------- + 
| DOs 1.70 207 16 | AS 64496 | Org A | 
| 10.1.0.0/20 | AS 64496 | Org A | 
4+---------------------------------------------- + 


+------------------- = ETNE TTE A + 
| asID | address | maxLength 

a ee E a N ee TEET + 
| 64496 | 10.1.0.0/16 | 16 

| 00 [==--------------------------------- + 
| | 10.1.0.0/20 | 20 

a a a + 
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3.3. Aggregate with a More Specific from a Different ASN 


An organization (Org A with ASN 64496 and ASN 64511) has been 
allocated the prefix 10.1.0.0/16. It wishes to announce the more 
specific prefix 10.1.0.0/20 from ASN 64511 as well as the aggregate 
route from ASN 64496 such that relying parties interpret the routes 
as intended. 


The desired announcements (and organization) would be: 


4--------------------------------------------- + 
| Prefix | Origin AS |Organization | 
4--------------------------------------------- + 
| 10.1.0.0/16 | AS 64496 | Org A | 
| 10.1.0.0/20 | AS 64511 | Org A | 
4--------------------------------------------- + 


aaa = SS 2 5 SS + 
| asID | address | maxLength 

+-------------------- = = = + 
| 64496 | 10.1.0.0/16 | 16 | 
dS HS A SS a a + 
fa SS SSS SS SSeS SSS Sa Ss SS ae eee se aase + 
| asID | address | maxLength 

Se eS + 
| 64511 |) 1615-00720 | 20 | 
+-------------------- TA A E E T + 


3.4. Sub-Allocation to a Multi-Homed Customer 


An organization (Org A with ASN 64496) has been allocated the prefix 
10.1.0.0/16; it wishes to announce the more specific prefix 
10.1.0.0/20 from ASN 64496. It has further delegated 10.1.16.0/20 to 
a customer (Org B with ASN 64511) who is multi-homed and will 
originate the prefix route from ASN 64511. ASN 64496 will also 
announce the aggregate route such that relying parties interpret the 
routes as intended. 
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The desired announcements (and organizations) would be: 


+------------------------ - 5 = = = + 
| Prefix | Origin AS |Organization | 
+------------------------- = - = = == + 
| 10.1.0.0/16 | AS 64496 | Org A | 
| 10.1.0.0/20 | AS 64496 | Org A | 
| 10.1.16.0/20 | AS 64511 | Org B | 
+---------------------------- = = - = = + 


Org A 

ta A A E + 
| asID | address | maxLength 

hes Sasa R a es Ss ee eee esaa + 
| 64496 | 105120 .0/16 | 16 | 
| | -------------------=----=---------- + 
| | 10.1.0.0/20 | 20 | 
Fan nn a a aE + 
Org B 

E a Se pa eae nas ee r Se an eee eae + 
| asID | address | maxLength 

tise ean os eS See ee a Se eee ea + 
| 64511 | 10.1.16.0/20 | 20 | 
tee Sse eaSS> ssa RSSSe ssa SSS aa esse sae SS sSH5 + 

3.5. Restriction of a New Allocation 


An organization has recently been allocated the prefix 10.1.0.0/16. 
Its network deployment is not yet ready to announce the prefix and 
wishes to restrict all possible announcements of 10.1.0.0/16 and more 
specifics in routing using RPKI. 


The following announcements would be considered undesirable: 


4+-------------------------- = -- = - = === === + 
| Prefix | Origin AS |Organization | 
4+-------------------------- = -- == === == + 
| 10.1.0.0/16 | ANY AS | ANY | 
| 10.1.0.0/20 | ANY AS | ANY | 
| 10.1.17.0/24 | ANY AS | ANY | 
4+-------------------------- = -- === === === + 
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The issuing party should create a ROA containing the following: 


tan a a a EAN I S + 
| asID | address | maxLength 
ees E O ee ee eee Se + 
| 0 | 10.1.0.0/16 | 32 | 
tan a aar e a e A E a SA + 
This is known as an AS 0 ROA [RFC6483]. Also, please see the 


definition and related comments in Section 1.3. 


3.6. Restriction of New ASN 
An organization has recently been allocated an additional ASN 64511. 
Its network deployment is not yet ready to use this ASN and wishes to 


restrict all possible uses of ASN 64511 using RPKI. 


The following announcement would be considered undesirable: 


4--------------------------------------------- + 
| Prefix | Origin AS |Organization | 
4--------------------------------------------- + 
| ANY | AS 64511 | ANY 

4--------------------------------------------- + 


It is currently not possible to restrict use of autonomous system 
numbers. 


3.7. Restriction of a Part of an Allocation 
An organization (Org A with ASN 64496) has been allocated the prefix 
10.1.0.0/16. Its network topology permits the announcement of 
10.1.0.0/17. Org A wishes to restrict any possible announcement of 


10.1.128.0/17 or more specifics of that /17 using RPKI. 


The desired announcement (and organization) would be: 


4--------------------------------------------- + 
| Prefix | Origin AS |Organization | 
4--------------------------------------------- + 
| 10.1.0.0/17 | AS 64496 | Org A | 
4--------------------------------------------- + 
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The following announcements would be considered undesirable: 


4--------------------------------------------- + 
| Prefix | Origin AS |Organization | 
4--------------------------------------------- + 
| 10.1.128.0/17 | ANY AS | ANY | 
| 10.1.128.0/24 | ANY AS | ANY | 
4--------------------------------------------- + 


+---------------------------------------------- + 
| asID | address | maxLength 
+---------------------------------------------- + 
| 64496 | 10.1.0.0/17 | 17 
+---------------------------------------------- + 
+---------------------------------------------- + 
| asID | address | maxLength 
+---------------------------------------------- + 
| 0 | 10.1.128.0/17 | 32 | 
+---------------------------------------------- + 


3.8. Restriction of Prefix Length 


An organization (Org A with ASN 64496) has been allocated the prefix 
10.1.0.0/16; it wishes to announce the aggregate and any or all more 
specific prefixes up to and including a maximum length of /20, but 
never any more specific than a /20. 


Examples of the desired announcements (and organization) would be: 


Ppa = Se Se ee ee ee ee ee ate + 
| Prefix | Origin AS |Organization | 
fana SS SS See a ee Ses + 
| 10.1.0.0/16 | AS 64496 | Org A | 
| 10.1.0.0/17 | AS 64496 | Org A | 
| ae | AS 64496 | Org A | 
| 10.1.128.0/20 | AS 64496 | Org A | 
oS SS Se T SS See E SSeS aS + 
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The following announcements would be considered undesirable: 


4--------------------------------------------- + 
| Prefix | Origin AS |Organization | 
4--------------------------------------------- + 
| 10.1.0.0/21 | ANY AS | ANY | 
| 10.1.0.0/22 | ANY AS | ANY | 
| eve | ANY AS | ANY | 
| 10.1.128.0/24 | ANY AS | ANY | 
4--------------------------------------------- + 


Hoa DSSS Slee SS SoS eS Se ee eS Se See aes + 
| asID | address | maxLength 

HS SS Se SSeS sae SS SS Se SS See Se eee Secs + 
| 64496 | 10.1.0.0/16 | 20 

Sa A aa gaa a ie E + 


3.9. Restriction of Sub-Allocation Prefix Length 


An organization (Org A with ASN 64496) has been allocated the prefix 
10.1.0.0/16. It sub-allocates several /20 prefixes to its multi- 
homed customers: Org B with ASN 64501 and Org C with ASN 64499, 
respectively. It wishes to restrict those customers from advertising 
any corresponding routes more specific than a /22. 


The desired announcements (and organizations) would be: 


4--------------------------------------------- + 

| Prefix | Origin AS |Organization | 

4--------------------------------------------- + 

| 10.1.0.0/16 | AS 64496 | Org A | 
10.1.0.0/20 AS 64501 Org B 
10.1.128.0/20 AS 64499 Org C 

| HO ded 0729 | AS 64501 | Org B | 

4--------------------------------------------- + 
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The following example announcements (and organizations) would be 
considered undesirable: 


4--------------------------------------------- + 
| Prefix | Origin AS |Organization | 
4--------------------------------------------- + 
| 10.1.0.0/24 | AS 64501 | Org B | 
| 10.1.128.0/24 | AS 64499 | Org c | 
10.1.0.0/23 ANY AS ANY 
4--------------------------------------------- + 


The issuing party (Org A) should create ROAS containing the 


following: 
For Org A 
ta nn E + 
| asID | address | maxLength 
ta nn O E ERE E A T + 
| 64496 | 10.1.0.0/16 | 16 
sn CE ES E E TE C + 
For Org B 
tan nn a + 
| asID | address | maxLength 
tan nn EN + 
| 64501 | 10.1.0.0/20 | 22 
o r a nn T A, + 
For Org C 
tan E E E + 
| asID | address | maxLength 
RTT AAAA EA a E SAE + 
| 64499 | 10.1.128.0/20 | 22 
e nn E E E + 
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3.10. Aggregation and Origination by an Upstream Provider 


Consider four organizations with the following resources, which were 
acquired independently from any transit provider. 


4------------------------------------------------- + 
| Organization | ASN | Prefix 
4+------------------------------------------------- + 
Org A AS 64496 10.1.0.0/24 
Org B AS 64505 10.1.3.0/24 
| Org c | AS 64499 | 10.1.1.0/24 
| Org D | AS 64511 | 10.1.2.0/24 
4------------------------------------------------- + 


These organizations share a common upstream provider Transit X 
(ASN 64497) that originates an aggregate of these prefixes with the 
permission of all four organizations. 


The desired announcements (and organizations) would be: 


pe a a R Se eS Sass = + 
| Prefix | Origin AS | Organization | 
Hoos SSR SSeS SS SSS SS SS Se es eS Se See ae + 
| 10.1.0.0/24 | AS 64496 | Org A | 
| 10.1.3.0/24 | As 64505 | Org B 

| 10.1.1.0/24 | AS 64499 [Ore | 
| 10.1.2.0/24 | AS 64511 | Org D 

| 10.1.0.0/22 | AS 64497 | Transit X | 
hea E R aS Sn eS ee eS Se eee + 


It is currently not possible for an upstream provider to make a valid 
aggregate announcement of independent prefixes. However, the issuing 
parties should create ROAS containing the following: 


Org A 

tan a a a E R + 
| asID | address | maxLength 

he N A R Se ae S + 
| 64496 | 10.1.0.0/24 | 24 

Fan a a a S a a a + 
Org B 

e Meiera a e a a EEE E N EA EEES + 
| asID | address | maxLength 

ta nn a a a + 
| 64505 | 10.1.3.0/24 | 24 

ta S a E a a a a + 
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Org C 
+------------------------ = 5 = + 
| asID | address | maxLength 
+-------------------- -- -- = 5 5 + 
| 64499 || BOs 0724 | 24 
+------------------------ 5 5 + 
Org D 
+------------------------- -- == = 5 + 
| asID | address | maxLength 
+------------------------ = 5 + 
| 64511 | 10.1.2.0/24 | 24 
+------------------------ 5 + 
3.11. Rogue Aggregation and Origination by an Upstream Provider 


Consider four organizations with the following resources that were 
acquired independently from any transit provider. 


Pe SSS SSS SSS SSS SSS Se SSS SS SSS SS SSeS SSS + 
| Organization | ASN | Prefix 
+----------------------- === = + 
| Org A | AS 64496 | 10.1.0.0/24 

| Org B | AS 64503 | 10.1.3.0/24 

| Org c | AS 64499 | 10.1.1.0/24 

| Org D | AS 64511 | 10.1.2.0/24 

heS SS ees SS] sess Ss See See SSeS Se See ase ss= + 


These organizations share a common upstream provider Transit X 

(ASN 64497) that originates an aggregate of these prefixes where 
possible. In this situation, Org B (ASN 64503, 10.1.3.0/24) does not 
wish for its prefix to be aggregated by the upstream provider. 


The desired announcements (and organizations) would be: 


+------------------------ - 5-5 5 = + 

| Prefix | Origin AS | Organization | 

+------------------------ - --- 5 = + 

| 10.140 0724 | AS 64496 | 68g A | 
10.1.3.0/24 AS 64503 Org B 
10.1.1.0/24 AS 64499 Org. Cc 

| 10.1.2.0/24 | AS 64511 | Org D 

| 10.1.0.0/23 | AS 64497 | Transit X | 
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The following announcement would be considered undesirable: 


4---------------------------------------------- + 
| Prefix | Origin AS | Organization | 
4---------------------------------------------- + 
| 10.1.0.0/22 | AS 64497 | Transit X | 
4---------------------------------------------- + 


It is currently not possible for an upstream provider to make a valid 
aggregate announcement of independent prefixes. However, the issuing 
parties should create ROAS containing the following: 


Org A 

E A a E E + 
| asID | address | maxLength 

tS SSR aS SSS aaa aS eee ee eee ae ee eee + 
| 64496 | 10.1.0.0/24 | 24 

Fan nn e A E + 
Org B 

e eee en EE EEE EN E T EE + 
| asID | address | maxLength 

e a A r AS + 
| 64503 | 10.1.3.0/24 | 24 

e a E a a a a + 
Org C 

tan A a A E + 
| asID | address | maxLength 

ta N A E a A A A A E + 
| 64499 | 10.1.1.0/24 | 24 

fa Sa See ee ae ee ee + 
Org D 

tan T A E S E + 
| asID | address | maxLength 

tan nen + 
| 64511 | 10.1.2.0/24 | 24 

tan E E + 


4. Adjacency or Path Validation Use Cases 


Use cases pertaining to adjacency or path validation are beyond the 
scope of this document and would be addressed in a separate document. 
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5. Partial Deployment Use Cases 
5.1. Parent Does Not Participate in RPKI 


An organization (Org A with ASN 64511) is multi-homed and has been 
assigned the prefix 10.1.0.0/20 from its upstream (Transit X with 
ASN 64496). Org A wishes to announce the prefix 10.1.0.0/20 from 
ASN 64511 to its other upstream(s). Org A also wishes to create RPKI 
statements about the resource; however, Transit X (ASN 64496), which 
announces the aggregate 10.1.0.0/16, has not yet adopted RPKI. 


The desired announcements (and organization with RPKI adoption) 
would be: 


4---------------------------------------------------- + 
| Prefix | Origin AS |Organization | RPKI | 
4---------------------------------------------------- + 
| 10.1.0.0/20 | AS 64511 | Org A | yes | 
| 10.1.0.0/16 | AS 64496 | Transit X | No | 
4---------------------------------------------------- + 


RPKI is strictly hierarchical; therefore, if Transit X does not 
participate in RPKI, Org A is unable to validly issue RPKI objects. 


5.2. Only Some Children Participate in RPKI 


An organization (Org A with ASN 64496) has been allocated the prefix 
10.1.0.0/16 and participates in RPKI; it wishes to announce the more 
specific prefix 10.1.0.0/20 from ASN 64496. It has further delegated 
10.1.16.0/20 and 10.1.32.0/20 to customers Org B with ASN 64511 and 
Org C with ASN 64502 (respectively), who are multi-homed. Org B 

(ASN 64511) does not participate in RPKI. Org C (ASN 64502) 
participates in RPKI. 


The desired announcements (and organizations with RPKI adoption) 


would be: 
HHS Sse SSSSS ss SSS SS SSeS SSeS eS Sa eS Se SSeS sSSess + 
| Prefix | Origin AS |Organization | RPKI | 
da SSeS SSSR Rea SS ee Se Se Ee Sa ee SS See Sat Ses + 
| 10.1.0.0/16 | AS 64496 | Org A | yes | 
| 10.1.0.0/20 | AS 64496 | Org A | yes | 
| 10.1.16.0/20 | AS 64511 | Org B | No | 
| 10.1.32.0/20 | AS 64502 | Org c | yes | 
RE E S a a 5 5 5 + 
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The issuing parties should create ROAs containing the following: 


Org A 
+------------------- = - E TNE TETE AT + 
| asID | address | maxLength 

n M r E a ee ee + 
| 64496 | 10.1.0.0/16 | 16 
+------------------ 5-5 E + 
| | 10.1.0.0/20 | 20 

e SSS SSS SS SS ee See Se a a esse + 


4---------------------------------------------- + 
| asID | address | maxLength 
4+---------------------------------------------- + 
| 64511 | 10.1.16.0/20 | 20 
4+---------------------------------------------- + 
Org C 
4+---------------------------------------------- + 
| asID | address | maxLength 
4---------------------------------------------- + 
| 64502 | 10.1.32.0/20 | 20 
4+---------------------------------------------- + 


5.3. Grandchild Does Not Participate in RPKI 
Consider the previous example, with an extension by which Org B, who 
does not participate in RPKI, further allocates 10.1.17.0/24 to Org X 
with ASN 64505. Org X does not participate in RPKI. 


The desired announcements (and organizations with RPKI adoption) 


would be: 
t--------------------- - 5 = + 
| Prefix | Origin AS |Organization | RPKI | 
+------------------ - 5 5 = + 
| 10.1.0.0/16 | AS 64496 | Org A | yes | 
| 10.1.0.0/20 | AS 64496 | Org A | yes | 
10.1.16.0/20 AS 64511 Org B No 
1.0:::1432.0/20 AS 64502 Org C Yes 
| LO yl 0/24 | AS 64505 | Org X | No | 
+-------------------- 5-5 = + 
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The issuing parties should create ROAs containing the following: 


Org A 
+------------------- = - E TNE TETE AT + 
| asID | address | maxLength 

n M r E a ee ee + 
| 64496 | 10.1.0.0/16 | 16 
+------------------ 5-5 E + 
| | 10.1.0.0/20 | 20 

e SSS SSS SS SS ee See Se a a esse + 


+---------------------------------------------—- + 
| asID | address | maxLength 
+---------------------------------------------- + 
| 64511 | 10.1.16.0/20 | 20 
+---------------------------------------------- + 


eae ea a es ee Se aa + 
| asID | address | maxLength 
+------------------- = - 5 = + 
| 64505 | 10.1.17.0/24 | 24 

Fena eS ee eS aa + 
Org C 

HHS SS5 5535558 S56 a5 SSS Sse aes sace + 
| asID | address | maxLength 
+--------------------- = E E + 
| 64502 | 10.1.32.0/20 | 20 

Se a E pe eee + 


6. Transfer Use Cases 


For transfer use cases, based on the preceding sections, it should be 
easy to deduce what new ROAs need to be created and what existing 
ROAs need to be maintained (or revoked). The resource transfer and 
timing of revocation/creation of the ROAs need to be performed based 
on the make-before-break principle and using suitable Regional 
Internet Registry (RIR) procedures (see Section 2.1). 


6.1. Transfer of In-Use Prefix and Autonomous System Number 


Org A holds the resource 10.1.0.0/20, and it is currently in use and 
originated from AS 64496 with valid RPKI objects in place. Org B has 
acquired both the prefix and ASN and desires an RPKI transfer ona 
particular date and time without adversely affecting the operational 
use of the resource. 
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The following RPKI objects would be created/revoked: 


For Org A, revoke the following ROA: 


+--------------------- = 5 + 
| asID | address | maxLength 

a a ee oe oe eee + 
| 64496 | 10.1.0.0/20 | 20 
+------------------- A T A AE + 


hanna a a a + 

| asID | address | maxLength 

ta nn E E + 

| 64496 | 10.1.0.0/20 | 20 

AA aa A a T + 
6.2. Transfer of In-Use Prefix 


March 2013 


Org A holds the resource 10.1.0.0/16, and it is currently in use and 


originated from AS 64496 with valid RPKI objects in place. 


Org A has 


agreed to transfer the entire /16 address block to Org B and will no 
longer originate the prefix or more specifics of it. Consequently, 

Org B desires an RPKI transfer of this resource on a particular date 
and time. This prefix will be originated by AS 64511 as a result of 


this transfer. 
The following RPKI objects would be created/revoked: 


For Org A, revoke the following ROA: 


+-------------------- = - 5 a + 
| asID | address | maxLength 

fe a ee ee eee ee + 
| 64496 | 10.1.0.0/16 | 16 | 
+------------------ == T S T + 


For Org B, add the following ROA when the 
resource certificate for 10.1.0.0/16 is issued 
to them (Org B): 


O + 

| asID | address | maxLength 

eae SS SS SS R Se SS SS eae = + 

| 64511 | 10.1.0.0/16 | 16 | 

Teseennrnen een e ee Se A E + 
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6.3. Transfer of Unused Prefix 


Org A holds the resources 10.1.0.0/16 and AS 64507 (with RPKI 
objects). Org A currently announces 10.1.0.0/16 from AS 64507. 

Org B has acquired an unused portion (10.1.4.0/24) of the prefix from 
Org A and desires an RPKI transfer on a particular date and time. 

Org B will originate a route 10.1.4.0/24 from AS 64496. 


The following RPKI objects would be created/sustained: 


For Org A, leave the following ROA unchanged: 


+---------------------------------------------- + 
| asID | address | maxLength 

$---------------------------------------------- + 
| 64507 | 10.1.0.0/16 | 16 | 
$---------------------------------------------- + 


For Org B, add the following ROA when the 
resource certificate for 10.1.4.0/24 is issued 
to them (Org B): 


+---------------------------------------------- + 
| asID | address | maxLength 

+---------------------------------------------- + 
| 64496 | 10.1.4.0/24 | 24 | 
+---------------------------------------------- + 


Org A may optionally provide ROA coverage for Org B by creating the 
following ROA preceding the RPKI transfer. The ROA itself is then 
naturally revoked when 10.1.4.0/24 is transferred to Org B’s resource 
certificate. 


Org A adds the following ROA: 


+---------------------------------------------—- + 
| asID | address | maxLength 

+---------------------------------------------- + 
| 64496 | 10.1.4.0/24 | 24 | 
+---------------------------------------------- + 


7. Relying Party Use Cases 
7.1. Prefix-Origin Validation Use Cases 


These use cases try to systematically enumerate the situations a 
relying party may encounter while receiving a BGP update and making 
use of ROA information to interpret the validity of the prefix-origin 
information in the routes derived from the update. We enumerate the 
situations or scenarios and include a recommendation for the expected 
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outcome of prefix-origin validation. For a description of prefix- 
origin validation algorithms, see [RFC6483] and [RFC6811]. We use 
the terms Valid, Invalid, and NotFound as defined in [RFC6811] and 
summarized earlier in Section 1.3. Also see [RFC6472] fora 
recommendation to deprecate AS_SETs in BGP updates. The use cases 
described here can be potentially used as test cases for testing and 
evaluation of prefix-origin validation in router implementations; 
see, for example, [BRITE]. 

7.1.1. Covering ROA Prefix, maxLength Satisfied, and AS Match 
ROA: {10.1.0.0/16, maxLength = 20, AS 64496} 
Route has {10.1.0.0/17, Origin = AS 64496} 


Recommended RPKI prefix-origin validation interpretation: Route is 
Valid. 


Comment: The route prefix has a covering ROA prefix, and the route 
origin ASN matches the ROA ASN. This is a straightforward prefix- 
origin validation use case; it follows from the primary intention 
of creation of the ROA by a prefix holder. 

7.1.2. Covering ROA Prefix, maxLength Exceeded, and AS Match 

ROA: {10.1.0.0/16, maxLength = 20, AS 64496} 

Route has {10.1.0.0/22, Origin = AS 64496} 


No other covering ROA 


Recommended RPKI prefix-origin validation interpretation: Route is 
Invalid. 


Comment: In this case, the maxLength specified in the ROA is 
exceeded by the route prefix. 


7.1.3. Covering ROA Prefix, maxLength Satisfied, and AS Mismatch 
ROA: {10.1.0.0/16, maxLength = 24, AS 64496} 
Route has {10.1.88.0/24, Origin = AS 64511} 


No other covering ROA 
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Recommended RPKI prefix-origin validation interpretation: Route is 


Invalid. 
Comment: In this case, an AS other than the one specified in the ROA 
is originating the route. This may be a prefix or subprefix 


hijack situation. 
7.1.4. Covering ROA Prefix, maxLength Exceeded, and AS Mismatch 
ROA: {10.1.0.0/16, maxLength = 22, AS 64496} 
Route has {10.1.88.0/24, Origin = AS 64511} 
No other covering ROA 


Recommended RPKI prefix-origin validation interpretation: Route is 
Invalid. 


Comment: In this case, the maxLength specified in the ROA is 
exceeded by the route prefix, and also an AS other than the one 
specified in the ROA is originating the route. This may be a 
subprefix hijack situation. 

7.1.5. Covering ROA Prefix Not Found 
Route has {10.1.3.0/24, Origin = AS 64511} 


No covering ROA 


Recommended RPKI prefix-origin validation interpretation: Route’s 
validation status is NotFound. 


Comment: In this case, there is no covering ROA for the route 
prefix. It could be a prefix or subprefix hijack situation, but 
this announcement does not contradict any existing ROA. During 
partial deployment, there would be some legitimate prefix-origin 
announcements for which ROAs may not have been issued yet. 

7.1.6. Covering ROA Prefix and the ROA Is an AS 0 ROA 

ROA: {10.1.0.0/16, maxLength = 32, AS 0} 

Route has {10.1.5.0/24, Origin = AS 64511} 


Recommended RPKI prefix-origin validation interpretation: Route’s 
validation status is Invalid. 
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Comment: An AS 0 ROA implies by definition that the prefix listed in 
it and all of the more specifics of that prefix should not be used 
in a routing context [RFC6483] [ASO-PROC]. Also, please see 
related comments in Section 1.3. 


7.1.7. Covering ROA Prefix Not Found but ROAs Exist for a Covering Set 
of More Specifics 


ROA: {10.1.0.0/18, maxLength = 20, AS 64496} 


ROA: {10.1.64.0/18, maxLength = 20, AS 64496} 


ROA: {10.1.128.0/18, maxLength 20, AS 64496} 


ROA: {10.1.192.0/18, maxLength = 20, AS 64496} 


Route has {10.1.0.0/16, Origin AS 64496} 


No covering ROA 


Recommended RPKI prefix-origin validation interpretation: Route’s 
validation status is NotFound. 


Comment: In this case, the route prefix is an aggregate (/16), and 
it turns out that there exist ROAs for more specifics (/18s) that, 
if combined, can help support validation of the announced prefix- 
origin pair. But it is very hard in general to break up an 
announced prefix into constituent more specifics and check for ROA 
coverage for those more specifics, and hence this type of 
accommodation is not recommended. 


7.1.8. AS_SET in Route and Covering ROA Prefix Not Found 


Route has {10.1.0.0/16, AS_SET [AS 64496, AS 64497, AS 64498, 
AS 64499] appears in the rightmost position in the AS_PATH} 


No covering ROA 


Recommended RPKI prefix-origin validation interpretation: Route’s 
validation status is NotFound. 


Comment: An extremely small percentage (70.1%) of external BGP 
(eBGP) updates are seen to have an AS_SET in them; this is known 
as proxy aggregation. In this case, the route with the AS_SET 
does not conflict with any ROA (i.e., the route prefix has no 
covering ROA prefix). Therefore, the route gets NotFound 
validation status. 
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7.1.9. Singleton AS in AS_SET (in the Route), Covering ROA Prefix, and 
AS Match 


Route has {10.1.0.0/24, AS_SET [AS 64496] appears in the rightmost 
position in the AS_PATH} 


ROA: {10.1.0.0/22, maxLength = 24, AS 64496} 


Recommended RPKI prefix-origin validation interpretation: Route is 
Invalid. 


Comment: In the spirit of [RFC6472], any route with an AS_SET in it 
should not be considered valid (by ROA-based validation). If the 
route contains an AS_SET and a covering ROA prefix exists for the 
route prefix, then the route should get an Invalid status. 

(Note: AS match or mismatch consideration does not apply.) 


7.1.10. Singleton AS in AS_SET (in the Route), Covering ROA Prefix, and 
AS Mismatch 


Route has {10.1.0.0/24, AS_SET [AS 64496] appears in the rightmost 
position in the AS_PATH} 


ROA: {10.1.0.0/22, maxLength = 24, AS 64511} 


Recommended RPKI prefix-origin validation interpretation: Route is 
Invalid. 


Comment: If the route contains an AS_SET and a covering ROA prefix 
exists for the route prefix, then the route should get an Invalid 


status. (Note: AS match or mismatch consideration does not 
apply.) 


7.1.11. Multiple ASs in AS_SET (in the Route) and Covering ROA Prefix 


Route has {10.1.0.0/22, AS_SET [AS 64496, AS 64497, AS 64498, 
AS 64499] appears in the rightmost position in the AS_PATH} 


ROA: {10.1.0.0/22, maxLength = 24, AS 64509} 
No other covering ROA 


Recommended RPKI prefix-origin validation interpretation: Route is 


Invalid. 

Comment: If the route contains an AS_SET and a covering ROA prefix 
exists for the route prefix, then the route should get an Invalid 
status. 
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7.1.12. Multiple ASs in AS_SET (in the Route) and ROAs Exist for a 
Covering Set of More Specifics 
ROA: {10.1.0.0/18, maxLength = 20, AS 64496} 
ROA: {10.1.64.0/18, maxLength = 20, AS 64497} 
ROA: {10.1.128.0/18, maxLength = 20, AS 64498} 


ROA: {10.1.192.0/18, maxLength 


20, AS 64499} 


Route has {10.1.0.0/16, AS_SET [AS 64496, AS 64497, AS 64498, 
AS 64499] appears in the rightmost position in the AS_PATH} 


No covering ROA 


Recommended RPKI prefix-origin validation interpretation: Route’s 
validation status is NotFound. 


Comment: In this case, the aggregate of the prefixes in the ROAs is 
a covering prefix (i.e., exact match or less specific) relative to 
the route prefix. The ASs in each of the contributing ROAs 
together form a set that matches the AS_SET in the route. But it 
is very hard in general to break up an announced prefix into 
constituent more specifics and check for ROA coverage for those 


more specifics. In any case, it may be noted once again that in 
the spirit of [RFC6472], any route with an AS_SET in it should not 
be considered valid (by ROA-based validation). In fact, the route 


under consideration would have received an Invalid status if the 
route prefix had at least one covering ROA prefix. 


7.2. ROA Expiry or Receipt of a CRL Revoking a ROA 


Here we enumerate use cases corresponding to router actions when RPKI 
objects expire or are revoked. In the cases that follow, the terms 
"expired ROA" or "revoked ROA" are shorthand and describe the expiry 
or revocation of the End Entity (EE) or resource certificate that 
causes a relying party to consider the corresponding ROA to have 
expired or been revoked, respectively. 


7.2.1. ROA of Parent Prefix Is Revoked 


A certificate revocation list (CRL) is received that reveals that the 
ROA {10.1.0.0/22, maxLength = 24, ASN 64496} is revoked. Further, a 
route exists in the Internet routing system for 10.1.3.0/24 
originated from ASN 64496. In the absence of said revoked ROA, no 
covering ROA prefix exists for the route prefix (i.e., 10.1.3.0/24). 


Manderson, et al. Informational [Page 27] 


RFC 6907 RPKI Use Cases and Interpretations March 2013 


The Relying Party interpretation would be: Route’s validation status 
is NotFound. 


7.2.2. ROA of Prefix Revoked while Parent Prefix Has Covering ROA 
Prefix with Different ASN 


A CRL is received that reveals that the ROA {10.1.3.0/24, 

maxLength = 24, ASN 64496} is revoked. Further, a route exists in 
the Internet routing system for 10.1.3.0/24 originated from 

ASN 64496. Additionally, a valid ROA exists for a parent prefix 
10.1.0.0/22, and said ROA is {10.1.0.0/22, maxLength = 24, 

ASN 64511}. No other covering ROA exists for the 10.1.3.0/24 prefix. 


The Relying Party interpretation would be: Route is Invalid. 
7.2.3. ROA of Prefix Revoked while That of Parent Prefix Prevails 


A CRL is received that reveals that the ROA {10.1.3.0/24, 
maxLength = 24, ASN 64496} is revoked. Further, a route exists in 
the Internet routing system for 10.1.3.0/24 originated from 

ASN 64496. Additionally, a valid ROA exists for a parent prefix 


10.1.0.0/22, and said ROA is {10.1.0.0/22, maxLength = 24, 
ASN 64496}. 


The Relying Party interpretation would be: Route is Valid. 


(Clarification: Perhaps the revocation of the ROA for prefix 
10.1.3.0/24 was initiated just to eliminate redundancy.) 


7.2.4. ROA of Grandparent Prefix Revoked while That of Parent Prefix 
Prevails 


A CRL is received that reveals that the ROA {10.1.0.0/20, 
maxLength = 24, ASN 64496} is revoked. Further, a route exists in 
the Internet routing system for 10.1.3.0/24 originated from 

ASN 64496. Additionally, a valid ROA exists for a parent prefix 
10.1.0.0/22, and said ROA is {10.1.0.0/22, maxLength = 24, 

ASN 64496}. 


The Relying Party interpretation would be: Route is Valid. 


(Clarification: The ROA for less specific grandparent prefix 
10.1.0.0/20 was revoked or withdrawn.) 
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7.2.5. Expiry of ROA of Parent Prefix 


A scan of the ROA list reveals that the ROA {10.1.0.0/22, 

maxLength = 24, ASN 64496} has expired. Further, a route exists in 
the Internet routing system for 10.1.3.0/24 originated from 

ASN 64496. In the absence of said expired ROA, no covering ROA 


prefix exists for the route prefix (i.e., 10.1.3.0/24). 


The Relying Party interpretation would be: Route’s validation status 
is NotFound. 


7.2.6. Expiry of ROA of Prefix while Parent Prefix Has Covering ROA 
with Different ASN 


A scan of the ROA list reveals that the ROA {10.1.3.0/24, 

maxLength = 24, ASN 64496} has expired. Further, a route exists in 
the Internet routing system for 10.1.3.0/24 originated from 

ASN 64496. Additionally, a valid ROA exists for a parent prefix 
10.1.0.0/22, and said ROA is {10.1.0.0/22, maxLength = 24, 


ASN 64511}. No other covering ROA exists for the prefix (i.e., 
10.1.3.0/24). 


The Relying Party interpretation would be: Route is Invalid. 
7.2.7. Expiry of ROA of Prefix while That of Parent Prefix Prevails 


A scan of the ROA list reveals that the ROA {10.1.3.0/24, 

maxLength = 24, ASN 64496} has expired. Further, a route exists in 
the Internet routing system for 10.1.3.0/24 originated from 

ASN 64496. Additionally, a valid ROA exists for a parent prefix 
10.1.0.0/22, and said ROA is {10.1.0.0/22, maxLength = 24, 

ASN 64496}. 


The Relying Party interpretation would be: Route is Valid. 


7.2.8. Expiry of ROA of Grandparent Prefix while That of Parent Prefix 
Prevails 


A scan of the ROA list reveals that the ROA {10.1.0.0/20, 

maxLength = 24, ASN 64496} has expired. Further, a route exists in 
the Internet routing system for 10.1.3.0/24 originated from 

ASN 64496. Additionally, a valid ROA exists for a parent prefix 
10.1.0.0/22, and said ROA is {10.1.0.0/22, maxLength = 24, 

ASN 64496}. 


The Relying Party interpretation would be: Route is Valid. 
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9. Security Considerations 

This memo requires no security considerations. 
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